WARNING: This document is subject to change at any time.  Any changes made
 will be indicated by a vertical bar (|) in column 1 of the file.
|Last update: 04/27/93
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 The following is the standard message header (128 byte block) with only
 slight modifications:

 typedef struct {
   char    Status;
   bassngl MsgNumber;
   bassngl RefNumber;
   char    NumBlocks;      <- see bit #7 of ExtendedStatus
   char    Date[8];
   char    Time[5];
   char    ToField[25];
   bassngl ReplyDate;
   char    ReplyTime[5];
   char    ReplyStatus;
   char    FromField[25];
   char    SubjField[25];
   char    Password[12];
   char    ActiveFlag;
   char    EchoFlag;
   char    Reserved1[4];    <- reserved was 6 bytes
   char    ExtendedStatus;  <- new byte - 0 for compatibility, accept 32 also
   char    Reserved2;       <- last of original reserved bytes
 } msgheadertype;

 The message base format remains almost 100% identical to the PCBoard v14.x
 standard.  In fact, it remains 100% compatible having just one byte
 different, which was not previously used by PCBoard.

 The byte at offset 126 (i.e.  the 127th byte of the 128 byte header) has a
 new function.  It is now used to indicate that extended header information
 will be found in the body of the message.

 The byte, referenced as ExtendedStatus above, will contain a 0 by default to
 indicate that no extended header information is available.  A value of 32
 will also be accepted to indicate the same thing since some programs may be
 placing a space instead of a null character in the reserved byte(s).

 If ExtendedStatus is not equal to 0 or 32 then it is assumed that extended
 header information is available, however, a follow-up check of the message
 body will determine the true existence, or lack thereof, of such information.

 For speed purposes, ExtendedStatus will be divided into 'bits' as follows:

   bit 0 = extended header has TO information
   bit 1 = extended header has FROM information
   bit 2 = extended header has SUBJECT information
   bit 3 = extended header has CARBON LIST TO information
   bit 4 = extended header has ATTACHED FILE information
   bit 5 = ignore - this bit is equal to decimal 32
   bit 6 = extended header has either REQRR or ACKRR information
   bit 7 = reserved for future use

 Bit 6 indicates that either an REQRR (request return receipt) or an ACKRR
 (acknowledge return receipt) extended header is in the message.

 The following structure will be used within the contents of a message body
 whenever an extended header is to be included:

 typedef struct {
   int   Ident;        16639 (40FF hex)
|  char  Function[7];  TO,TO2,FROM,FROM2,SUBJECT,ATTACH,LIST,ROUTE,ORIGIN,
                        REQRR,ACKRR,ACKNAME,PACKOUT
   char  Colon;        always set to ":"
   char  Descript[60]; user name, subject, filename
   char  Status;       NONE, READ (if LIST)
   char  CarReturn;    0xE3 or 0x0D
 } msgextendtype;

 There can be as many extended headers as desired.  In fact, no headers at
 all is possible even though the ExtendedStatus from the message header told
 PCBoard to expect to find one.  This, of course, has a negative impact on
 efficiency (don't set the flag unless you really intend to put an extended
 header in the body of the message) but maintains complete compatibility with
 previous versions of PCBoard which totally ignored the values found where
 the ExtendedStatus byte is now located.

 The first field, Ident, serves to indicate that a truly valid header is
 about to follow.  Ident is an integer value of 40FFh.  Stored in the file
 it is seen as an ascii 255 character followed by an @ character.

 Older software will not expect this extended header to be in there and will
 display the header to the user.  The format of the information, however, is
 such that it will be meaningful, albeit, somewhat annoying to see.

|The function of the header is written in english.  Right now the following
|are valid values for PCBoard:  "TO     ", "TO2    ", "FROM ", "FROM2  ",
|"SUBJECT", "ATTACH ", "LIST ", "ROUTE ", "ORIGIN ", "REQRR  ", "ACKRR  ",
|"ACKNAME" and "PACKOUT".  Any other values are permissable but will be
|ignored by PCBoard v15.0 unless and until future updates to PCBoard add
|new-standards.

 The next character in the header is a colon which is then followed by the
 appropriate text for the header.  For example, the header might be
 structured like this:

    <255><@>SUBJECT:any subject you wish to put here, up to 60 characters

 Notice how an older program, which is not PCB v15.0-aware, will still
 display something intelligible to the user who is reading the message.
 Because the entire text is in english the user will be faced with extra
 information that is not utilized by the software he is using, but at the
 same time, the extra information does not make his software incompatible or
 unusable.  This protects the user's investment in software and time,
 especially if the author is no longer supporting the program, or the user
 does not have time to switch programs or upgrade to a newer package which
 may have more bells and whistles than he cares to learn.

 Of course, older packages will not be able to take advantage of the added
 functionality since the header information will be very difficult to enter
 properly via the keyboard.  So, while remaining compatible with older
 software, to take advantage of the new features a user will still have to
 upgrade to a newer release of the package.

 The text for the header may be up to 60 bytes long.  If the Function is set
 to "TO" then the header indicates a longer, or alternate, name should be
 used when displaying the TO:  field of the message.  If the Function is set
 to "LIST" then the header indicates the name of ONE of the users who is to
 receive the message.  There may be more than one "LIST" header, in fact, it
 is expected that any time you create a carbon copy list you will be sending
 the message to two or more users.  If the Function is set to "FROM" then it
 indicates a longer, or alternate, name should be displayed for the FROM:
 field.  If set to "SUBJECT" then a longer, or alternate, subject is
 displayed.  If set to "ATTACH" then the description field indicates the name
 of the attached file.  If set to ROUTE then message routing information (for
 netmail transfers) will be included.  If set to ORIGIN then the origin of
 the message (for netmail transfers) will be included.  If set to REQRR then
 PCBoard will generate a Return Receipt when the user reads the message
 online.  Mail Doors will need to be enhanced to perform the same
 functionaility.  If set to ACKRR this will indicate that an acknowledgement
 to the Return Receipt is contained in the message.  One additional header,
 the ACKNAME, will be included with ACKRR to complete the acknowledgement.

 The next byte is the extended header status byte.  To help guarantee that
 the header is valid, there are only three possible values for this field.
 They are:  'N', and 'R'.  These values are used as follows:

    'N' indicates that there is no status - it is used just for verification
    'R' indicates that a user in a CARBON COPY LIST has read the message

 The 'R' allows PCBPack to determine when all intended recepients have read
 the message.  Each user is listed in a separate header and each user
 therefore has a separate status byte to indicate when it has been read.
 Once all users have read the message it may then be deleted.

 Finally, the CarReturn byte is set to E3 hex.  This is the same character
 that is normally used by PCBoard to indicate the end of a line.  By
 terminating the header in this manner all non-v15.0-aware packages will be
 able to properly display the entire header in a legible form.  The 0D hex
 value is used by foreign systems (such as the Chinese version of PCBoard) in
 place of E3.  This is because E3 interferes with the double-byte character
 system used by these countries.

 Remember too, that other systems/software could pass other values through
 the extended header field.  PCBoard v15.0 will ignore (and not display)
 any extended headers it does not understand.  Thus, if an offline reader
 were to pass additional information into the message base it would be posted
 and downloaded through any of the existing mail doors.  The downloader then,
 having access to an updated reader, could take advantage of the additional
 information that was passed to it.  For instance, a header of "GIF" might be
 passed as well as a filename.  If the door were updated to know that it
 should send the attached file too then the offline reader could use the
 extended header "GIF" to know that it can display the file to the caller.
 Possibilities are limitless.